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(57) Support for cross-language proxies is provided. A 
runtime component maintains an internal, language- 
independent token corresponding to each object exposed 
across a language boundary. Each exposed object is 
represented in the foreign language by a proxy object 
Whenever a reference to an object is passed across a 
language boundary, it is the token that is passed If the 
reference to be passed is a proxy object, then the token is 
retrieved from the proxy and passed 
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TRANSPARENT USE OF COMPILED OR INTERPRETED OBJECTS 
IN AN OBJECT ORIENTED SYSTEM 

ABSTRACT 

Support for cross-language proxies is provided. A runtime component maintains an internal, 
language-independent token corresponding to each object exposed across a language boundary. Each 
exposed object is represented in the foreign language by a proxy object. Whenever a reference to an 
object is passed across a language boundary, it is the token that is passed. If the reference to be 
passed is a proxy object, then the token is retrieved from the proxy and passed. 
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TRANSPARENT USE OF COMPILED OR INTERPRETED OBJECTS 
IN AN OBJECT ORIENTED SYSTEM 

Field of the Invention 

The present invention relates, in general, to the field of mixed object oriented language programming 
environments. The invention provides a mechanism to support cross-language proxies in such an 
environment where the requester (client) does not know what the target language is. 

Background of the Invention 

Concurrently-filed application titled Uniform Access To And Interchange Between Objects 
Employing A Plurality Of Access Methods" (IBM Docket No. CA997013), which is commonly 
assigned, describes in some detail the general nature of object oriented programming languages. 

Briefly, object oriented (00) technology is based on the notions of "object" and "class inheritance". 
An object is a reusable package of data that is a member of a class. The class provides the definition 
for a set of operations that can be performed on the object and other objects that are members of the 
same class. Classes can be related to one other by inheritance, and the properties, behaviours, data 
and operations of a parent or "base" class (a class without member objects), may be inherited with 
or without modification in a derived class under the control of a programmer. 

OO programming languages, such as C++ and OO COBOL, are compiled languages. In C++, for 
example, the compiler defines an object data structure for each class. This structure includes the 
layout of the data members and, where appropriate, a virtual function table to implement indirect 
calls. 

Other OO programming languages, such as Java and Smalltalk are interpreted languages. These 
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typically use a virtual machine to process source code or partially pre-compiled source code to calls 
to base functions or "primitives" resident in the virtual machine. 

The notion of "proxies" assisting in providing local transparency for access to remote objects is 
5 discussed in the above referenced concurrently-filed application (IBM Docket No. CA997013). 
Proxies allow the uniform invocation of methods for same-language support, irrespective of the 
location of the objects. However, proxies alone are not sufficient to provide location transparency 
in the presence of cross-language calls. 

10 Summary of the Invention 

It is an object of the present invention to provide a mechanism for transparent access to compiled or 
interpreted objects, irrespective of the nature of the object oriented programming environment from 
which the call is initiated. 

15 , 

It is also an object of the present invention to provide transparent access from a C++ environment 
to objects implemented variously in Java, OO COBOL and Smalltalk. 

It is also an object of the present invention to provide access from program written in a "client" 
20 language or a combination of several client languages, to objects resident in the same process and 
implemented in an "implementation" language. The client and implementation languages can include 
C++, Java, COBOL, Smalltalk and other applicable OO languages. 

It is also an object of the present invention to enable the roles of "client" and "implementation" be 
25 freely intermixed, such that any implementation of a first object in a first programming language may 
concurrently function as a client of a second object implemented in a second language, whether the 
second language is identical to or distinct from the first language. 
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It is also an object of the present invention that the access provided from a client language to an 
implementation language shall be "transparent", with the meaning that the construction of the 
program functioning in a client role shall not depend on the identity of the implementation language. 

5 Accordingly, the present invention provides a method for effecting an access request from a client 
in a first language environment to an implementation object in a second language environment. The 
method includes the steps of converting the access request into a language-independent token, 
passing the token to the second language environment, and converting the token into an access 
request having parameters appropriate to the second language environment. 

10 

The invention also provides a mechanism for effecting cross-language access requests in an 
computing environment. This mechanism consists of a runtime component having means for 
generating language independent tokens representing implementation object, means for caching 
generating tokens, including reference means for locating cached tokens representing specific 
IS implementation objects, and means for passing access requests in a first language on implementation 
objects in a second language through tokens representing said implementation objects. 

Computer program products embodying the above method steps are included as a non-obvious 
combination. 

20 

Brief Description of the Drawings 

Embodiments of the invention will be described in detail in association with the accompanying 
drawings in which: 

25 Figures 1 to 3 are schematic diagrams illustrating the interfaces between clients and 

cross-language objects, according to aspects of the invention; and 

Figures 4 to 6 are flow diagrams illustrating the steps to issue a cross-language call under the 
schemes illustrated in Figures 1 to 3. 
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Detailed Description of the Preferred Embodiments 

The three principal elements of the invention are the proxies provided in the client language or 
5 languages, a dispatcher provided in the implementation language, and a runtime component which 
supports the generation, maintenance, and manipulation of language-independent object tokens each 
of which corresponds to an object made available for access from other languages. 

In the preferred embodiment of the invention, the proxies provide client access to an object in 
10 accordance with the standards and practices defined by the Object Management Group's Common 
Object Request Broker Architecture (OMG CORBA). These standards specify an Interface 
Definition La n gua g e (IDL), a set of data types usable from IDL, and how these data types and other 
IDL artifacts are to be represented in different programming languages. 

IS In the preferred embodiment, the proxies and dispatcher convert data types and object accesses 
between the language-specific forms mandated by the OMG CORBA standards and 
language-independent forms. The language-independent object token, a "SOMReF in the preferred 
embodiment, is one of these forms, and is created, destroyed, invoked, and manipulated by the 
proxies and dispatcher using the support provided by the runtime component. 

20 

The above described technology provides a solution for mixing Java and C++, and is extensible to 
include at least Smalltalk and OO COBOL. 

Figure 1 schematically illustrates a cross-language method call from client language A to an 
25 implementation language B. Figure 4 is a flow diagram illustrating the sequence of steps taken to 
implement-this call. 

Referring generally to Figure 1, the client 2 is presumed to have acquired, through means described 
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below, a reference 3 to a proxy object 4. As shown in block 100 of Figure 4, the client 2 uses 
reference 3 to invoke a method on the proxy object 4, which supports a method corresponding to 
each method supported by the target implementation 12. 

The method of the proxy object 4 converts all parameters into their language-independent forms 
(block 102 of Figure 4). The proxy also determines the identity of the SOMRef 8 that represents the 
implementation (block 104 of Figure 4). This is accomplished either by consulting a pointer 6 to the 
SOMRef stored in the instance data of the proxy 4, or by consulting a separate lookup table (not 
shown). The proxy object's method then invokes an entry point in the runtime, passing the pointer 
to the taiget SOMRef 8, the language-independent forms of the parameters, and an identifier for the 
method to be called (block 106 of Figure 4). 

The runtime component stores in each SOMRef 8 a pointer or collection of pointers 9 to a dispatcher 
10. Dispatchers may be shared by multiple instances of an implementation, and in that case the 
SOMRef also stores a pointer 16 to the implementation itself The dispatcher for a compiled language 
consists of a collection of functions, one for each method supported by the implementation. The 
implementation passes the address of each such function to the runtime before the first 
implementation object 12 is created, and the runtime saves these pointers in its collection of pointers 
9. Using the method identifier given it by the proxy, the runtime selects the corresponding dispatch 
function pointer from its collection of pointers and calls it with the value of the pointer 16 to the 
implementation and the language-independent forms of the parameters (block 108 of Figure 4). 

The dispatcher function converts the parameters from their language-independent forms into the 
language-dependent forms appropriate to language B (block 1 10 of Figure 4). It then invokes the 
method on the implementation 12, converts any return value or exception into a 
language-independent form, and returns it back through the runtime to the client 2 (blocks 1 12, 1 14 
and 116 of Figure 4). 
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Dispatches for interpreted languages such as Java and Smalltalk are objects with dispatcher methods 
rather than collections of dispatcher functions. Instead of selecting a function pointer from a 
collection of such pointers, the runtime uses the existing invocation capabilities of the Java or 
Smalltalk interpreter to invoke an appropriate dispatch method on the dispatcher object. The 
subsequent operation of the dispatch method is as described for the compiled language dispatch 
functions. 

Figure 2 illustrates a more complex example in which object references are passed as parameters. 
Figure 5 is the corresponding flow diagram illustrating the sequence of steps. 

Referring generally to Figure 2, client 22 has a pointer 23 to the proxy 24 for the target object 
implemented m language B. The client also has pointers 20 to an object implemented in language A, 
and 21 to a second proxy for a second object implemented in language B. 

As before, client 22 calls a method on proxy 24 (block 120 of Figure 5), but this time included in the 
parameters of the call are the pointer values 20 and 21. Parameters are again converted by the proxy 
into a language-independent form (block 122 of Figure 5). The language-independent form of an 
object reference is the SOMRe£ and proxy 24 converts pointer 2 1 into its language-independent form 
by finding the SOMRef 48 associated with the proxy 44. 

In the preferred embodiment, all proxies inherit a common base class and the SOMRef pointer 46 is 
stored as instance data introduced by the common base class. Proxy 24 can convert the parameter 
pointer into a SOMRef by accessing that instance data, either directly or through an accessor method 
also introduced by the common proxy base class, whichever is more appropriate for the language A. 

Other means including lookup tables can be used to store the correspondence between proxies and 
SOMRefs in embodiments that do not utilize a common base class. 
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The proxy also converts pointer 20 into a SOMRef (block 126 of Figure 5). In the preferred 
embodiment, implementations also inherit the common base class and therefore proxy 24 can access 
the SOMRef pointer 78 in the implementation 72 just as it was able to do so in the proxy 44. 

5 However, to reduce the time and space associated with SOMRef construction SOMRefs are not 
created for implementations until they are required, and therefore, pointer 78 may be null if the 
implementation 72 has not previously been used in a cross-language call. If pointer 78 is null, proxy 
24 will use the runtime facilities to allocate a SOMRef 68 for the implementation and will store the 
SOMRefs address into pointer 78 for future reuse (blocks 124, 128 of Figure 5). 

10 

The method call proceeds through the runtime as before and a dispatch method or function in the 
dispatcher 30 is invoked (blocks 130, 132 of Figure 5). Among the language-independent form 
parameters it receives are the SOMRefs 48 and 68, which it must convert into forms appropriate for 
the language B. 

15 

First the dispatcher invokes a function in the runtime to test whether the object behind the SOMRef 
48 is implemented in language B (block 134 ofFigure 5). This runtime function takes as arguments 
the SOMRef pointer, an integer value to identify language B drawn from a roster of language 
identifiers created for this purpose, and the name of the desired interface on the target object. The 

20 runtime passes this request on to dispatcher 50, which finds that the language identifier does match 
the implementation language B. Dispatcher 50 then returns a native language reference to the named 
interface ofimplementation object 52, through the runtime back to dispatcher 30, which then passes 
this native reference on its call to implementation object 32 (blocks 136, 138 ofFigure 5). In this way 
implementation 32 receives a direct reference to same-language implementation 52 and can use it 

25 directly without further involvement of any proxies or of the runtime. 

Dispatcher 30 also performs the same check for SOMRef 68, but when the language identifier is 
checked in dispatcher 70 it is found not to match language A. Dispatcher 3 0 then proceeds by calling 
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a second runtime function to query the SOMRef to detennine whether an appropriate language B 
proxy already exists for it (blocks 136, 140 of Figure 5). The SOMRef maintains a collection 74 of 
pointers to proxies, indexed by language and interface identifiers. If an appropriate proxy is found it 
will be used in the call to implementation 32, otherwise dispatcher 30 allocates a new proxy 64 and 
associates it with SOMRef 68, including adding it to the collection 74 indexed by the correct 
language and interface identifiers (blocks 142, 144, 146 of Figure 5). 

Returning of object references as return values is identical to the procedure described above except 
that the dispatcher object converts implementation and proxy references into SOMRefs, and the proxy 
object converts SOMRefs back into implementation and proxy references (blocks 148, 150, 152 of 
figure 5). 

Given one initial cross-language reference through a proxy, SOMRef, and dispatcher, the passing of 
object references as parameters and return values allows any number of other objects to be exposed 
between languages. 

Figure 3 schematically illustrates how a client in language A receives an initial reference to a 
cross-language object without first possessing one. Figure 6 is the corresponding flow diagram. 

Initially only the client 82 and proxy class 83 exist in language A (referring generally to Figure 3). 
The proxy class consists of proxy behaviours that are accessible by name without requiring the 
existence of a proxy instance. The precise form taken by these behaviors is language dependent: for 
C++ or Java they appear as C++ static methods, and in Smalltalk as class methods. 

One of the proxy class behaviors is a "create" function. Client 82 calls the create function provided 
by proxy class 83 (block 160 of Figure 6). The create function calls a runtime entry point, passing 
it the name of the class for which an instance is to be created (block 162 of Figure 6). The runtime 
maintains a table of implementations 87 indexed by class name, and looks up the desired class in that 
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The embodiments of the invention in which an exclusive property or privilege is claimed are defined 
as follows: 

1 . A method for effecting an access request from a client in a first language environment to an 
implementation object in a second language environment, comprising: 

converting the access request into a language-independent token; 
passing the token to the second language environment; and 

converting the token into an access request having parameters appropriate to the second 
language environment. 

2. A method, according to claim 1, wherein the step of converting the access request into a 
language independent token comprises: 

generating a proxy having methods corresponding to the implementation object; and 
passing a reference from the client to the proxy invoking methods in said proxy to convert all 
parameters in the access request to a language independent form. 

3. A method, according to claim 2, wherein the step of converting the access request into a 
language independent token further comprises: 

identifying a token representing the implementation object; and 
passing a pointer to the identified token. 



CA 02204974 1997-05-09 



CA9-97-014 



1 4. A mechanism for effecting cross-language access requests in a computing environment, 

2 comprising: 

3 a runtime component having means for generating language independent tokens representing 

4 implementation objects; 

5 means for caching generated tokens, including reference means for locating cached tokens 

6 representing specific implementation objects; and 

7 means for passing access requests in a first language on implementation objects in a second 

8 language through tokens representing said implementation objects. 

1 5. A mechanism, according to claim 4, further comprising means for converting all parameters 

2 of an access request in the first language into a language-independent form and for passing a pointer 

3 from said language independent form to a token representing a target implementation object for said 

4 access request. 

1 6. A mechanism, according to claim 6 wherein the runtime component further adapted to provide 

2 a dispatch function to convert the parameters of the access request to a language specific form 

3 appropriate to the target implementation object. 

1 7. A mechanism, according to claim 6, wherein the dispatch function comprises, in the case of 

2 a compiled object oriented language: 

3 a store of pointers to functions corresponding to each method supported by the target 

4 implementation; and 

5 means to match a method provided by the proxy with a pointer to one of the functions. 
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1 8. A mechanism, according to claim 6, wherein the dispatch function comprises, in the case of 

2 an interpreted object oriented language: 

3 objects having methods corresponding to each method supported by the target implementation 

4 object; and 

5 means in the runtime to invoke an appropriate dispatch method for the target implementation 

6 object on a object. 

1 9. A computer program product for effecting an access request from a client in a first language 

2 environment to an implementation object in a second language environment, said computer program 

3 product comprising: 

4 a computer readable storage medium having computer readable code means embodied in said 

5 medium, said computer readable code means comprising: 

6 computer instruction means for converting the access request into a language independent 

7 token; 

8 computer instruction means for passing the token to the second language environment; and 

9 computer instruction means for converting the token into an access request having parameters 
1 0 appropriate to the second language requirement. 
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